คณะวิศวกรรมศาสตร์
จุฬาลงกรณ์มหาวิทยาลัย
2110684
Information System Architecture สอบย่อยครั้งที่ 1
5 กค. 2547 18.00-20.00 น.
ข้อสอบมี 5 ข้อ รวม 30
คะแนน
1. (4 คะแนน)
ทำไมองค์กรขนาดใหญ่จึงต้องมีสิ่งที่เรียกว่า Information System Architecture
และการที่ว่า Information System Architecture เป็นเสมือนภาษานั้น หมายความว่าอย่างไร
(คำตอบตามคุณจีรวรรณ
พงษ์เกษตรกรรม) เพราะองค์กรขนาดใหญ่มีโครงสร้าง (structure) และองค์ประกอบ (component) ที่ซับซ้อน รวมทั้งมีกระบวนการ (process) และการถ่ายทอดข้อมูล (data)
ไปมาระหว่างกันภายในองค์กร Information System Architecture เปรียบเสมือนเป็น
overview หรือ layout หรือเรียกว่า
ภาพรวมของระบบต่าง ๆ ในองค์กร นอกจากนี้ ISA หมายรวมถึง
โครงสร้างการวางระบบของ Hardware (H/W Architecture) Software Architecture
และ Information Architecture ซึ่งก็คือ
โครงสร้างของข้อมูล (Data) ต่าง ๆ ที่ถูกใช้ในองค์กร (1)
ดังนั้น จึง
อาจกล่าวได้ว่า Information System
Architecture เปรียบเสมือน ภาษา หรือ illustration ใช้สำหรับแสดง (demonstrate) หรือ เป็นเครื่องมือ (tool)
สำหรับสื่อสารโครงสร้างต่าง ๆ
ในองค์กรให้กับผู้ที่อยู่ในองค์กรทราบ
นอกจากนี้ยังเป็นเสมือนภาษาที่ใช้สื่อสารระหว่าง Planner, Owner, Designer และ Builder ในองค์กร และใช้ถ่ายทอด จุดประสงค์ (objective)
มุมมอง (viewpoint) หรือ process ต่าง
ๆ จากทีมหนึ่งไปยังอีกทีมหนึ่ง ได้อีกด้วย เช่นถ่ายทอด
หรือสื่อความหมาย ของ Business Rules ไปยัง Designer
(System Analyst) เพื่อทำการ Design Process Model เป็นต้น (2)
2. (4 คะแนน) ยกตัวอย่าง major business
rules/model ตามแนวทางของ DOE มาสัก 5 อย่าง โดยใช้ภาควิชาวิศวกรรมคอมพิวเตอร์ จุฬาฯ เป็นกรณีศึกษา
(คำตอบตามคุณพิศาล
แก้วประภา)
1.
ผลิตผู้สำเร็จการศึกษา ทั้งในระดับ ปริญญาตรี โท เอก
2.
ศึกษาค้นคว้า วิจัย หาความรู้ทางวิชาการใหม่ ๆ
3.
เป็นที่ปรึกษาให้กับองค์กรของรัฐ เอกชน
ตามความต้องการขององค์กรนั้น ๆ ตามขอบเขต และความเกี่ยวข้อกับภาควิชา
4.
แลกเปลี่ยนเผยแพร่ความรู้ที่เกี่ยวข้องกับสาขาวิชา
กับองค์กรต่าง ๆ
5.
จัด อบรม สัมมนา เผยแพร่ความรู้ แก่บุคคลทั่วไป
(คำตอบตามคุณวิชชุพันธ์
อาวัชนาการ)
Major business
rules ตามแนวทางของ DOE โดยใช้ภาควิชาฯ
เป็นกรณีศึกษาได้แก่
(1) statement: Information
Architecture ของภาควิชาฯ ต้องสนับสนุนกับ information
architecture ของจุฬาฯ; rationale: เพื่อความเข้ากันได้ของข้อมูล,
ลดการสับสน implication: ทำเอกสารการออกแบบให้ชัดเจน (ข้อนี้เจ็บมาก
ดีจริง ๆ ยรรยง)
(2) statement: ควรแบ่งประเภทบุคคลให้การเข้าถึงข้อมูล, rationale: เพื่อป้องกันข้อมูลสำคัญต่าง ๆ implication
ทำระบบ farewall กำหนดชื่อ/กลุ่มผู้ใช้ (คำว่า farewall
สะกดอย่างนี้จริง ๆ ยรรยง)
(3) statement ระบบควรง่ายต่อการใช้งาน rationale: เพื่อใช้ผู้ใช้ที่ไม่มีความรู้มากเข้าใจการทำงาน
implication สอบถาม / ตรวจสอบ
กลุ่มผู้ใช้และความต้องการ
(4) statement: ควรทำระบบให้เป็น standard rationale:
เพื่อให้ง่ายต่อการใช้และสามารถตรวจสอบ / เปลี่ยนส่วนที่เสียได้ทันที implication ออกแบบให้เป็น stand และทำเอกสารกำกับ
(5) statement: ระบบต้องมีประสิทธิภาพและจำนวนเพียงพอต่อการใช้งาน rationale: เพื่อให้งานที่ออกมามีประสิทธิภาพและทันเวลา implication: ออกแบบระบบเผื่อการใช้งานเพิ่ม (และน่าจะตรวจสอบประสิทธิภาพการใช้งานอยู่สม่ำเสมอ
-> นั่นคือมีระบบตรวจสอบ เก็บสถิติ ฯลฯ ยรรยง)
3. (6 คะแนน) ถ้าประธานกรรมการธนาคารแห่งหนึ่ง
พบว่าค่าใช้จ่ายด้านไอทีของธนาคารสูงเกินกว่าจะรับได้ ต้องทำการ outsourcing
ออกไปให้กับบริษัทคอมพิวเตอร์ภายนอก
แต่ท่านประธานทราบดีว่าหัวใจหรือธุรกิจของธนาคารนั้นอยู่ที่ระบบไอที
ท่านประธานจึงหันไปหาทางออกจาก Zachman framework โดยการพิจารณาลำดับชั้น
(perspective) ของการทำระบบสารสนเทศที่เอื้อต่อองค์กร
และท่านประธานก็พบทางออก จงเดาใจท่านประธานว่า ทางออกนั้นคืออะไร
ทำอย่างไรจึงจะรักษา core business หรือแก่นแท้ของธุรกิจการธนาคารนั้นไว้ได้
ให้เหตุผลประกอบ
(คำตอบตามคุณพิศาล
แก้วประภา)
ขอเดาใจท่านประธานของธนาคารแห่งนี้ว่า เมื่อท่านมองและพิจารณา Zachman framework อย่างถี่ถ้วนแล้ว ท่านประธานก็ได้เห็นว่าแก่นแท้ของธุรกิจนั้น
ได้ถูกอธิบายไว้ในแถวที่ 1 และ 2
ของ ZF อยู่แล้ว
และมีรายละเอียดเพิ่มขึ้นในแถวที่ 3 ส่วนแถวอื่นต่อมานั้น
จะเน้นในมุมมองของการปฏิบัติงานจริง การนำไปใช้จริง เมื่อแบ่งกลุ่มชั้นของ Zachman ออกมาเป็น 2 ส่วนแล้ว ก็มาพิจารณาได้ว่า Business
จริง ๆ ของธนาคารจะอยู่ที่ส่วนบนทั้งหมด ส่วนแถวล่าง ๆ
จะเป็นส่วนที่ทำให้ส่วนบนเป็นจริงได้
หรืออีกนัยหนึ่งคือเป็นเหมือนแขนขาให้สำหรับส่วนบน เมื่อ Business เปลี่ยน ส่วนล่างเปลี่ยนตาม เพื่อรองรับกับส่วนบน ไม่ใช่ส่วนล่างเปลี่ยน
(เทคโนโลยีเปลี่ยน) แล้วให้ Business เปลี่ยนตาม (แต่เป็นไปได้นะที่เทคโนโลยีเปลี่ยนแล้วธุรกิจเปลี่ยนตาม
แต่ไม่ใช่เป็นการบังคับฝืนมาจากข้างล่าง แต่เป็นการที่เจ้าของธุรกิจจะทำความเข้าใจ
โดยมองเทคโนโลยีเป็นตัวชี้นำธุรกิจ เรียกว่าเทคโนโลยีในแง่มุมนี้ จะเข้ามาจากทางด้านบน
ยรรยง)
ท่านประธานเห็นว่าการที่จะยกให้
Outsource ทำทั้งหมดของ ZF ก็ไม่ต่างอะไรกับยกเอาธุรกิจไปให้กับบริษัท
Outsource นั้น ท่านจึงเล็งเห็นว่ามีความจำเป็นที่จะมีอำนาจของฝ่าย
IT 3 แถวแรกของ Zachman
เอาไว้ แล้วให้ outsource รับผิดชอบส่วนล่างไป อำนาจทาง Business ก็ยังคงจะมีอยู่ในมือต่อไป
การวางแผน หรือปรับเปลี่ยนกลยุทธทางธุรกิจก็ยังสามารถทำได้ สิ่งที่หายไป หรืองาน 3 แถวล่าง ก็ให้ Outsource รับผิดชอบไป ซึ่งตรงนี้ก็สามารถลดค่าใช้จ่ายด้าน
IT ลงไปได้เช่นกัน
สรุปแล้ว
ท่านประธานตัดสินใจ คงเหลือ IT บางส่วนไว้ เฉพาะส่วนที่เกี่ยวข้องกับ 3 แถวบน และ outsource ส่วนที่เหลือ 3 แถวล่างให้บริษัทภายนอกทำ
4. (8 คะแนน) หากบริษัทขนาดเล็กแห่งหนึ่งมีอุปกรณ์ switch
สำหรับเครือข่ายเพียงตัวเดียว
แต่มีกระบวนการที่จะเปลี่ยนตัวใหม่ทันทีที่ตัวที่ใช้งานอยู่เกิดเสียขึ้นมา
โดยการให้ร้านเจ้าประจำที่พันธ์ทิพย์ส่งตัวใหม่มาให้ทางมอเตอร์ไซต์
ถามว่ากระบวนการเช่นที่ว่านี้ ควรเป็นส่วนหนึ่งของ artifacts ในช่องไหนของ Zachman framework และควรอยู่ในส่วนใดของ
Armour ของ Mukherji และของ Spewak
ให้เหตุผลประกอบ
(ไม่มีคนตอบถูกใจครับ
- ยรรยง)
ก่อนอื่นต้องบอกว่า โจทย์กล่าวถึง กระบวนการ หรือ ขั้นตอนปฏิบัติ
ดังนั้นมันจะต้องเป็น เอกสารคู่มือที่หยิบใช้ได้ในขณะที่ router เกิดเสียขึ้นมา ดังนั้น artifact ชิ้นนี้ต้องไม่อยู่ในส่วนของ
design หรือของที่เป็น specification ใด
ๆ แต่ต้องอยู่ในส่วนที่เป็นการปฏิบัติงานจริงแล้ว และเป็นส่วนหนึ่งของระบบงาน
(ที่เป็นสนับสนุนหรือสำรอง)
ใน
Zachman นั้น ต้องอยู่ใน network column ชั้นล่างสุด
(ซึ่งแน่นอนว่าต้องได้รับการกำหนดมาจากระดับบน ในแง่ของ business rule ว่าต้องไม่เสียเกินเท่านั้นเท่านี้ชั่วโมง และตัว ขั้นตอนปฏิบัติ นี้ก็ต้องได้รับการออกแบบ และจัดสร้างในระดับ perspective ต่าง ๆ ที่เหมาะสม แต่โจทย์พูดถึง ตัวเล่ม ของคู่มือนี้
ใน
Armour นั้นต้องอยู่ในส่วนของ Infrastructure View ภายใต้ Business
View เพราะเป็นโครงสร้างพื้นฐาน (ทางเทคนิก) ที่รองรับอยู่
(รวมถึงกระบวนการที่ทำให้โครงสร้างพื้นฐานนี้อยู่ในสภาพที่ดีด้วย) ฝั่ง Architecture
principles นั้นเป็นเพียงหลักการ ไม่ได้เป็น คู่มือ หรือ ขั้นตอน
ที่ใช้ตอนทำงานจริงครับ
ใน
Mukherji นั้น ต้องอยู่ใน Systems View ซึ่งเกี่ยวกับระบบสนับสนุนส่วนที่เป็น
Operational View ทางด้านหนึ่งอาจมองว่าอยู่ใน Technical
View แต่ส่วนนี้เป็นเพียงแหล่งอ้างอิง ไม่ได้เป็นอะไรที่ ปฏิบัติงาน
ใน
Spewak นั้น ต้องอยู่ใน Technology Architecture แทน
เพราะส่วนนี้รวมถึง ขั้นตอนปฏิบัติ
สำหรับเทคโนโลยีที่อ้างอิงถึงเหล่านั้นด้วย จะเห็นว่านี่เป็นจุดอ่อนอย่างหนึ่ง
คือไม่มีองค์ประกอบของ framework สำหรับให้ระบบสนับสนุนอยู่
ไปรวมอยู่ใน technical reference model แทน
5. (8 คะแนน) จากการที่ท่านเป็นผู้ใช้ระบบสารสนเทศ (user) ของภาควิชาวิศวกรรมคอมพิวเตอร์มาได้สักระยะหนึ่งแล้ว
ท่านบอกได้หรือไม่ว่า technology reference model ของภาควิชาฯ
หน้าตาเป็นอย่างไร ความถูกต้องแม่นยำในเชิงเทคนิกไม่ใช่ประเด็นสำคัญของคำตอบ
แต่การแยกแยะองค์ประกอบของเทคโนโลยีให้เป็นไปตามหลักการถือเป็นประเด็นสำคัญ
(ไม่มีใครตอบดี ยรรยง)
Technology Reference Model คือรูปแบบของบรรดาเทคโนโลยีที่ใช้ในองค์กร ว่าใช้ มาตรฐาน อะไร อย่าลืมว่าการที่ไม่ใช่คำว่า มาตรฐาน นั้น เพราะบางอย่างเป็น de facto standard อย่างระบบของไมโครซอฟต์
ซึ่งไม่ใช่มาตรฐาน แต่ก็เหมือนใช่ เพราะใช้กันทั่วไป
สามารถแบ่งเป็นองค์ประกอบ
(หรือ area) ต่าง ๆ เช่น
ระบบเซิร์ฟเวอร์
Sparc/Solaris, Intel/Windows
Server software
Oracle,
Apache, SMTP for email
ระบบเครือข่าย
IP,
IEEE 802.1 (Ethernet), IEEE 802.11 (Wi-Fi)
DHCP
(แจก IP)
ระบบไมโครคอมพิวเตอร์
Intel/Windows
MS
Office, pdf
Software development tools
ODBC, Java, C++, VB, HTML,
XML, UML